Method and device for generating a single-use financial account number

ABSTRACT

A device for facilitating financial account transactions is described which includes a processing unit including a cryptographic processor. The device also includes an input unit, a display unit and a memory device connected to the processing unit. The memory device contains a private cryptographic key, a first data element and a second data element. The processing unit encrypts the first data element using the private cryptographic key and the second data element, modifies the second data element, combines the encrypted first data element and the second data element to generate a single-use financial account identifier, and displays the single-use financial account identifier. This identifier is then transmitted to a central processor for authorization of the transaction. The central processor extracts and decrypts data elements from the transmitted identifier using the private cryptographic key, compares those data elements with data elements stored in a memory, and verifies the single-use financial account identifier in accordance with the comparison.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is continuation of U.S. application Ser. No.11/422,986, filed on Jun. 8, 2006, which is a continuation of U.S.application Ser. No. 09/694,191, filed on Oct. 23, 2000, which is acontinuation of U.S. application Ser. No. 08/919,339, filed on Aug. 28,1997, now U.S. Pat. No. 6,163,771, the entire contents of which each ofthese is incorporated by reference.

BACKGROUND OF THE INVENTION

This invention relates to a method and a device for generating asingle-use, transaction-specific financial account number, therebyproviding a high level of security for financial transactions,particularly credit card transactions.

There are over 500 million general purpose, retail, oil and other creditcard accounts in the United States (hereafter called “cards”). Worldwidethe figure is almost 1 billion such cards. Typically, each authorizeduser of an account is issued a credit card: a physical plastic objectwith an embossed account number and cardholder name appearing on itsface. Anti-counterfeiting indicia, such as holograms, photographs orsignatures, may also appear on the card to discourage wrongful usage.

Since the credit card number is unchanging, there is a risk offraudulent use by anyone who steals the number. The key element ofdefense against a fraudulent user impersonating the authentic cardholderis signature verification. A signature area appears on the back of mostcards, and when a person receives a new credit card, he is instructed tosign his name on the back of the card. A merchant who accepts the cardwill then be able to compare the signature specimen that appears on theback of the card to the signature on the sales draft signed by theconsumer at the time of purchase. In some cases, the merchant may alsoask for photo ID before accepting the card or as a method of checkingthat the signatures are for the person whose name appears on the face ofthe card.

In addition to examining the signature on the card, most merchants whoaccept credit cards use a small device known as an authorizationterminal. The authorization terminal is capable of reading informationdisposed on a magnetic stripe located on the back of the credit card insome cases, this stripe also contains other difficult-to-counterfeitinformation. To process a credit card purchase, the merchant passes thecard through the magnetic stripe reader of the terminal and enters theamount of the purchase. The information is then sent by the device overa phone or wireless connection to a central database for account numberverification and purchase authorization. A card that has been reportedlost or stolen is declined. If magnetic stripes on credit cards becomedamaged and unreadable, the authorization terminal permits manual entryof the credit card number as it appears embossed on the face of thecard.

With the dramatic growth of direct marketing, an increasing share of allcard purchases are being made without the physical presentation of thecard to the selling merchant. Instead, the consumer simply relays thecard number to the merchant, and the merchant enters the card numberinto a computer terminal which is also designed to handle the orderprocessing function. As electronic commerce grows over the next decade,the percentage of such remote, non-face-to-face purchases can beexpected to grow. This poses an increasingly acute problem for theentire credit card system, since credit card numbers are highlyinsecure.

To protect against thieves fraudulently creating credit card numbers andthen using them for remote purchasing, a check-digit algorithm istypically employed for credit card account numbers which makes itcomparatively difficult (approximately 1 chance in 500,000) to pick arandom 16-digit number that is also a valid credit card account number.In addition, since not every valid credit card account number iscurrently in use, simply making up a valid number is, in itself, notenough to get an authorization code from the central authorizingnetwork. In addition to passing the check-digit test, a bank must haveissued that number to an active customer.

To further help combat mail-order based credit card fraud, both Visa andMasterCard have deployed databases that allow a merchant to verify thata given credit card account number is connected to a specific billingaddress. Visa calls this service the Address Verification Service. Thetheory behind the service is that a thief (for example, a dishonestrestaurant waiter) might be able to use a credit card receipt slip tosteal an active account number, but if he tries to use that number for amail order purchase he would not know the correct address associatedwith that number. Even if a thief were to obtain the cardholder'saddress, this service can allow a merchant to compare the shippingaddress of the catalog order to the current billing address for thataccount number and thus possibly identify any suspicious activity.

Currently, credit cards also incorporate an expiration date after whichthey are no longer valid. These dates are typically one to two yearsafter the card is issued. The reason for an expiration date is to reducethe issuing bank's risk of cards being presented after an account isclosed. Since the expiration date is an absolute indication of whetheror not to accept a card, an old card that is lost or misplacedeventually expires with minimal risk that it will be found and usedimproperly.

In addition, credit card information and transaction information may beencrypted using well known encryption schemes like RSA's public keycryptography. For example, SET is a joint Visa/MasterCard standard forencrypting credit card numbers transmitted over the Internet.

In spite of these safeguards, credit card security is vulnerable to anumber of attacks by unscrupulous persons. Some examples of theseattacks are as follows:

a) Theft of cards: Any conventional credit card which is stolen can bemisused, either at a merchant's establishment by forging the signatureon the card onto a sales slip, or by ordering merchandise or servicesremotely.

b) “Sniffing:” Credit card transaction information being transmittedover public networks can possibly be intercepted and captured or“sniffed.” The sniffed information can then be used to createcounterfeit cards and/or order goods and services. For example, if ahacker were to break the SET encryption scheme, the hacker could sniffout credit card numbers and misuse them. Re-submission of the sniffedencrypted credit card numbers to the same merchant is known as “replay.”

A large-scale attack on credit-card number security would threaten theentire credit card system. For example, if someone were to steal 1million active credit card account numbers, and were also able to stealthe billing addresses to which those cards were issued, the entirecredit card system would be threatened. At the very least, mail ordersales might have to be suspended until new safeguards were put in place.At worst, a flood of counterfeit cards, with correct account numbers andvalid names embossed on their faces, could be created.

With the advent of almost instantaneous worldwide money transfers, aband of organized thieves could clear hundreds of millions or evenbillions of dollars of charges through the authorization system and thenwire that money to a safe haven before cardholders suspected that theircards had been charged an unauthorized amount. If the theft alsoinvolved data revealing each account's unused available credit line,such criminal activity might be even harder to detect before it was toolate to rescind the wire transfers of stolen money.

Cards which store information, as opposed to merely having embossednumbers, are known in the art. Such “smart cards” are becomingincreasingly common. These cards contain a small microprocessor capableof storing data in a secure fashion and of performing computeroperations on such data. Smart cards may have built-in small numericdisplay screens. In particular, smart cards used for distribution ofcryptographic keys, display keys on their display screens.

Smart cards are used to authenticate card users and to authenticate thecard/user combination to a third party. These cards are also used forcontrolling access to computer systems and databases and entry intosecure areas. Northern Telecom offers a credit card sized smart cardcalled Entrust which contains a microchip that stores encoded, privatekeys. Hardware tokens such as Security Dynamics' SecurID card use a“time synchronous methodology” to produce passwords every 30 seconds.

Wire transfer calculator-style devices are also known in the art. Suchdevices are the size of a credit card and contain a tamper-resistant“secure perimeter” within which is disposed a clock and acryptoprocessor. These devices also have a small LCD alpha-numericdisplay screen and a numeric keypad for data entry.

A number of security devices and methods involving credit cards havebeen disclosed. For example, U.S. Pat. No. 5,311,594, “Fraud ProtectionFor Card Transactions,” describes a challenge-response method for fraudprotection wherein credit card holders are authenticated based on theirresponses to randomly asked questions like their mother's phone number,their graduation year, birth date, etc. The responses are checkedagainst prestored information in a database.

U.S. Pat. No. 5,457,747, “Anti-Fraud Verification System Using a DataCard,” describes a biometric system for deterring credit card fraud.Credit cards have two magnetic stripes, one that has been permanentlyencoded with the card holder's biometric information and one that an ATMcan write onto. To use the card, the card holder supplies the samebiometric information at a verification terminal. The terminal checksthe biometric information supplied by the card holder against thatrecorded on the magnetic stripe. If the biometrics match, the terminalwill write a transaction authorization onto the magnetic stripe.

U.S. Pat. No. 5,485,519, “Enhanced Security For a Secure Token Code,”describes a method for enhancing security for a private key stored in asmart card. A user input PIN is combined algorithmically with a coderesident in the smart card to produce the private key. The private keyis not stored in the smart card except for short intervals when the cardis actually being used by an authorized user who has input his PIN.

SUMMARY OF THE INVENTION

This invention provides a method and a device to facilitate secureelectronic commerce, secure remote credit card purchases, and secureconventional credit card purchases wherein the customer is assured thatthe merchant or an intercepting third party cannot misuse any creditcard information.

According to one aspect of our invention, a method for generating asingle-use financial account identifier is provided which includes thesteps of accessing a first data element specific to an account;accessing a second data element including transaction-specific data; andcombining the first data element and the second data element to producethe single-use financial account identifier.

According to another aspect of our invention, a device for facilitatingcredit transactions is provided which includes a processing unitincluding a cryptographic processor. The device also includes an inputunit connected to the processing unit for inputting information thereto,and a display unit connected to the processing unit for displaying aprocessing result. In addition, the device includes a memory deviceconnected to the processing unit. The memory device contains a privatecryptographic key, a first data element, a second data element and aprogram adapted to be executed by the processing unit. In accordancewith the program, the processing unit encrypts the first data elementusing the private cryptographic key and the second data element,modifies the second data element, combines the encrypted first dataelement and the second data element to generate a single-use financialaccount identifier, and displays the single-use financial accountidentifier using the display unit.

According to a further aspect of our invention, a system for verifying afinancial account identifier is provided which includes a processingunit including a cryptographic processor. The system also includes acommunications unit, connected to said processing unit, for transmittingand receiving information regarding the financial account identifier,and a memory device. The memory device-contains a private cryptographickey, a first data element, a second data element and a program adaptedto be executed by the processing unit. In accordance with the program,the processing unit receives a single-use financial account identifier,extracts therefrom a third data element and a fourth data element,decrypts the third data element using the private cryptographic key andthe fourth data element, compares the decrypted third data element withthe first data element in a first comparison, compares the fourth dataelement with the second data element in a second comparison, andverifies the received financial account identifier in accordance withthe first comparison and the second comparison.

According to still another aspect of our invention, a method forproviding a single-use financial account identifier includes the stepsof: providing a memory storing data representing a plurality ofpredetermined single-use financial account identifiers, datarepresenting a status for each single-use financial account identifier,and data representing a pointer to one of the single-use financialaccount identifiers; identifying the single-use financial accountidentifier based on the pointer data; and transmitting a signal to anoutput device to present the single-use financial account identifier.

According to a further aspect of our invention, a device for providing asingle-use financial account identifier is provided which includes amemory, an output device and a processor coupled to the memory and tothe output device. The memory stores data representing a plurality ofpredetermined single-use financial account identifiers, datarepresenting a status for each of the predetermined single-use financialaccount identifiers, and data representing a pointer to one of thepredetermined single-use financial account identifiers. The outputdevice presents the single-use financial account identifier. Theprocessor is configured to identify the single-use financial accountidentifier based on the data representing a pointer, and to transmit asignal to the output device to present the single-use financial accountidentifier.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of the hand-held smart card device inaccordance with the present invention.

FIG. 2 is a block diagram of the device's central processor.

FIG. 3A is a block diagram of the overall system of the presentinvention.

FIG. 3B is a flowchart showing the basic method of the presentinvention.

FIG. 4 is a block diagram of the credit card issuer's central processor,with databases as used in accordance with the first embodiment of theinvention.

FIG. 5 shows in tabular form the credit card account holder database.

FIG. 6 shows in tabular form the account holder secret key database.

FIG. 7 shows in tabular form the credit card transaction databaseaccording to the first embodiment of the invention.

FIG. 8 is a flowchart describing an encryption scheme used to generate asingle-use credit card number in accordance with the first embodiment ofthe invention.

FIGS. 9A and 9B are connected flowcharts describing the operationsperformed by the central processor of a credit card issuer to generatean authorization code, in accordance with the first embodiment of theinvention.

FIG. 10 is a flowchart describing the operations performed by a deviceto generate and display a single-use credit card number, in accordancewith a second embodiment of the invention.

FIGS. 11A and 11B are connected flowcharts describing the operationsperformed by a credit card issuer's central controller to generate anauthorization code, in accordance with the second embodiment of theinvention.

FIG. 12 is a block diagram of the credit card issuer's centralprocessor, with databases as used in accordance with the secondembodiment of the invention.

FIG. 13 shows in tabular form the credit card number database.

FIG. 14 shows in tabular form the credit card transaction databaseaccording to the second embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 is a schematic diagram of a device 100 for generating asingle-use credit card number in accordance with this invention. Thisdevice is preferably a smart card, hereinafter referred to as the“device.” The device has a keypad 103, a display screen 102, a memory104 and a central processor 101. Memory 104 contains a key 601, and CPU101 contains a cryptographic processor. The device may be activatedthrough the input of a unique cardholder identifier such as a personalidentification number (PIN) through the keypad 103. Alternatively, thedevice may include a biometric interface 105, and be activated by theinput of a suitable biometric record such as the cardholder'sfingerprint.

FIG. 2 is a schematic diagram showing further details of the centralprocessor 101 of device 100. The central processor 101 includes amicroprocessor 201. The microprocessor 201 is connected to a clock 202,a random-access memory (RAM) 203, a read-only memory (ROM) 204, and acryptographic processor 205. In addition, the microprocessor 201 isconnected to the keypad 103 for receiving input from the user and to thedisplay 102 for prompting the user or displaying information.

FIG. 3A is a schematic diagram of the environment in which the methodand system of the present invention are used. A cardholder 301, wishingto purchase goods or services from a merchant 302 (not necessarily inperson), transmits a single-use credit card number 300 to the merchant.The merchant 302 transmits the single-use credit card number 300 to acredit card issuer 303. The credit card issuer 303 returns anauthorization 310 to the merchant, based on which the merchant deliversthe desired goods or services 320 to the cardholder.

FIG. 3B shows the steps of the basic method of using the device inaccordance with the present invention. To purchase goods or services inperson, via telephone or via the Internet, cardholder 301 uses device100 to generate a transaction-specific, single-use credit card number.The cardholder first inputs his PIN or biometric data to access thedevice (step 351). If access is granted, the device responds by queryingthe cardholder on display 102 whether it should generate a single-usecredit card number (step 355). The cardholder responds by requestinggeneration of a credit card number (for example, by keying “YES”). Hemay optionally be asked to enter the amount of the purchase in step 356or a merchant code number provided by the merchant. This number could beonly a few digits long since it does not have to be unique to eachmerchant.

The device then generates a single-use credit card number (step 360);details of the card number generation are explained below. The number isunique for the specific input variables set by the cardholder or by thedevice. It may also be unique to the specific date and time to avoidso-called “replay” attacks for that card at that merchant with thatexact purchase amount. The single-use credit card number is preferably a16-digit number that can be recognized as a conventional credit cardnumber.

The cardholder transmits the single-use number to the merchant (step361), and the merchant enters the single-use number into anauthorization terminal connected to a central credit card processingsystem maintained by the credit card issuer (step 362). A check digitmay be included in the number to prevent the incorrect keying of thenumber. The number is sent to the credit card processing system forauthorization (step 363). The central system processor maps thesingle-use credit card number onto a conventional credit card accountand determines whether the transaction is authorized (step 380); if so,the central system returns an authorization code for display on themerchant's authorization terminal (step 390); if not, the central systemtransmits an authorization failed message for display on the merchant'sauthorization terminal (step 395).

Throughout this discussion, the term “credit card number” refers to anumber that is used only one time to perform a specific transaction, andis generated using the device 100; in contrast, the term “accountnumber” refers to an unchanging identifier for the cardholder which isstored in a database maintained by the card issuer.

FIRST EMBODIMENT Device Private Key Encryption

In this embodiment, the single-use credit card number is generated bythe device cryptoprocessor 205, using a private key 601 stored in thedevice memory 104 (preferably the ROM 204). The encryption data changeswith each use of the card, so that the single-use encrypted credit cardnumber is different for each transaction. This credit card number isdistinct from the unchanging account number identifying the particularcardholder. It should be noted that knowledge of the account number doesnot allow an attacker to generate a valid single-use credit card number.

When the single-use credit card number is transmitted to a merchant, themerchant passes the number to the card issuer's central processor forauthorization. The central processor decrypts the number based on aknown algorithm, determines the true account number, and eitherauthorizes or denies the charge.

FIG. 4 is a schematic diagram of the credit card issuer's centralprocessor 400. The processor includes a central processing unit (CPU)401. The CPU is connected to a clock 402, a random-access memory (RAM)403, a read-only memory (ROM) 404, a cryptographic processor 405, and acommunication port 406 for communication with the merchant's centralprocessor. In addition, the CPU 401 is connected to a storage device410, which includes a credit card account holder database 411, a creditcard account private key database 412, and a credit card transactiondatabase 413.

The data structure of the credit card account holder database 411 isshown in FIG. 5. Each record in the database includes the cardholderaccount number 501, the cardholder's name 502, address 503 and telephonenumber 504, the original credit line 505 associated with the account,the amount of credit currently available (available credit line 506),and the expiration date 507.

FIG. 6 shows the fields of the credit card account private key database412. Each entry of this database has the cardholder private key 601 andthe associated cardholder account number 501. The private key is thusstored in both the device memory 104 and the database 412. An additionalsecret piece of information, called a “nonce” 602, is associated withthe account number. The nonce is also stored in the device memory 104.The nonce need not be as long as the account number, but should not beeasily derived therefrom.

FIG. 7 shows the fields of the credit card transaction database 413.Each record of this database corresponds to one transaction using thecard, and includes the account number 501, the expiration date 507 ofthe card, the transaction amount 702, the merchant identification number703 and an initialization variable 704. The initialization variable 704is used to ensure that each credit card number is unique to theparticular transaction, thereby preventing a “replay” attack.

In this embodiment, the device memory 104 has stored therein the privatekey 601, the nonce 602, the initialization variable 704 and the accountnumber 501. The initialization variable is set at 0 (zero) when the cardis newly issued, and is incremented each time a single-use credit cardnumber is generated.

The cryptography described herein requires binary data. Current creditcard numbers are 16-digit decimal numbers. Since 10¹⁶ is only slightlygreater than 2⁵³, nearly every such decimal number may be represented bya 53-digit binary number. Therefore, in the following discussion it willbe assumed that the credit card number is a 53-bit number and that it isthen converted to a 16-digit decimal number for transmission or display.

A credit card number consists of an m-bit initialization variable(abbreviated IV), an a-bit account number, and an n-bit nonce(abbreviated N), where m+a+n=53. It should be noted that the nonce maytake the place of the check code employed with conventional credit cardnumbers. If n=16, then the probability that an attacker can generate avalid credit card number is 1 in 2^(m)=65536. The parameter n can bevaried to change the probability as desired.

The parameters m and a do not necessarily have to be the same size forall credit card holders. However, m should be large enough for anyindividual cardholder so that he does not use his credit card more than2^(m) times before the card expires. For most credit card holders avalue of m=9 would probably suffice, allowing use of the card 512 times(that is, 5 times a week assuming the card is valid for two years)before it expires.

The steps for generating an encrypted single-use credit card numberaccording to this embodiment are shown in FIG. 8. In step 801, thedevice central processor 101 retrieves the nonce 602 and theinitialization variable 704 from the device memory 104. In step 802, thenonce is encrypted using the user's private key K and the IV. Thus

C=E _(K)(N, IV)

where C represents the encrypted nonce. Both N and C are n-bit values.

The central processor 101 then retrieves the account number from thedevice memory 104 (step 803). In step 804, the encrypted nonce C, theinitialization variable IV, and account number A are concatenated toform an encrypted, single-use credit card number CCN:

CCN=C_IV_A, where _ denotes concatenation.

The initialization variable is incremented and the result is stored inthe device memory 104 (step 805):

IV=IV+1

The resulting credit card number CCN is then displayed on the displayscreen 102 (step 806) and read, shown or otherwise transmitted to themerchant. The merchant transmits this number to the issuer's centralprocessor 400 for authorization of the transaction.

FIGS. 9A and 9B show the steps for generating an authorization code forthe transaction. In step 901 the issuer's central processor 400 receivesthe single-use credit card number transmitted by the merchant.

To verify the card number, the credit card issuer's central processorfirst extracts the encrypted nonce C, the initialization variable IV,and account number A from the credit card number (step 902). Theprocessor then retrieves the extracted account number from thecardholder account database 411 (step 903), and determines whether theaccount number is valid (step 904). If the account number is not valid,the transaction is aborted (step 905). If the account number is valid,the processor looks up the account number in the credit card transactiondatabase 413 to determine whether the card holder has previously usedthe initialization variable IV (step 906). If the cardholder has doneso, the transaction is aborted (step 908). If the initializationvariable has not been used, the incremented initialization variable isstored in the credit card transaction database 413 (step 908).

In step 921, the processor retrieves the card holder's private key K inthe private key database 412. The private key K then is used to decryptthe encrypted nonce (step 922). This recovers the original nonce N:

N=D _(K)(C, IV).

The decrypted nonce N is compared against the nonce 602 stored in theaccount private key database 412 (step 923). If they match (step 924)then the credit card number is considered valid; otherwise thetransaction is aborted (step 925).

If the card is found to be valid, and if the cardholder's account meetsthe credit card issuer's approval criteria (step 926), then the issuer'scentral processor generates an authorization code and transmits the codeto the merchant (step 928). If not, then the transaction is aborted(step 927).

Approval criteria are issuer specific and may include, but are notlimited to, the following: account must be in good standing (not pastdue); sufficient credit must be available (some issuers may approvepurchases that exceed available credit by a specified margin), the cardshould not have been reported stolen/lost; and the account should not beclosed.

There are two types of ciphers which can be used to encrypt the data (inthis embodiment, the nonce N and initialization variable IV): streamciphers and block ciphers. Stream ciphers can be used with minormodification so that different initialization variables will result indifferent ciphertext. The amount of information that must be encryptedin this system is smaller than the blocksize of most block encryptionalgorithms. However, a modified variant of Cipher Feedback Mode may beused to encrypt small amounts of data and has some additional securityfeatures.

Accordingly, one possible encryption method uses a stream cipher.Conventional ciphers use a secret key k to produce a stream of data. Thedata is then combined with the unencrypted data (e.g. by XORing themtogether) to produce the encrypted text. On the other hand, to encryptan n-bit value N using initialization variable IV and key k, a streamcipher may be used to generate n(IV+1) bits of data, with N thencombined with the last n bits of the resulting data.

Another way to encrypt the data is to use a block cipher in 1-bitfeedback CFB-mode. However, this has some undesirable properties whichmay allow an attacker to deduce the unencrypted form of encrypted data.While an attacker cannot generate a valid credit card number withoutknowledge of the user's private key, knowing the user's nonce underminesthe security of the account. To avoid this problem the following variantmay be used:

1. The input of the block cipher I_(i) consists of the IV concatenatedwith a 1-m bit shift register (where m is the number of bits in the IVand we are using a 1-bit block cipher). Let S_(i) be the state of theshift register. Then

S₀=1

and

I₀=IV_S₀.

In fact,

I_(i)=IV_S_(i)

for all i.

2. Bit i of the encrypted data is computed as

C _(i) −f(I _(i) ,k)₀ ⊕P _(i)

where f is the encryption function of the block cipher and f(I/k)₀denotes bit 0 of the encryption of I with key k.

3. The shift register is updated with the ciphertext so that

S _(i+1)=(S _(i)<<1)_(—) C _(i)

where S<<1 denotes shifting S left 1 bit.

To decrypt the data a nearly identical algorithm is used except thatP_(i) and C_(i) are reversed. So the second step of the algorithm is allthat changes and it becomes:

2′) Bit i of the decrypted data is computed as

P _(i=f)(I _(i) ,k)₀ ⊕C _(i)

where f is the encryption function of the block cipher and f(I,k)₀denotes bit 0 of the encryption of I with key k.

Suitable block ciphers include Triple-DES, IDEA and Blowfish. Suitablestream ciphers include RC4, SEAL and A5. All of these algorithms arediscussed in B. Schneier, “Applied Cryptography,” John Wiley & Sons, 2ded. 1996.

The primary defense against replay attacks in this embodiment ischecking that the same initialization variable IV is not used twice forany particular account number. When the credit card is issued theinternal IV is preferably set to 0. Each time the credit card is usedthe IV increments by 1. Therefore, as long as the cardholder does notuse the credit card more than 2^(M) times (where the IV is m bits long)the same initialization variable will never be repeated. Preferably, thecredit card issuer keeps track of the IVs that the card holder has used.This can be done with a simple bit array where entry a of the arrayindicates that IV a has been used if and only if it is set to 1.

As stated earlier, m=9 is probably sufficient for most cardholders. Thismeans that the card issuer needs only keep track of a 512-bit array foreach such credit card. This is very inexpensive. In addition, if theissuer notices that the cardholder has nearly exhausted his IVs, then itcan issue the cardholder a new card.

Another attack against this system would be to flood the central serverwith bogus credit card numbers (otherwise known as a denial-of-serviceattack). One way to make this attack more difficult is to spread theauthorization processing load across several servers which all have thecapability of verifying a credit card number. If they receive a validcredit card number, they can coordinate with the central server toperform the credit card transaction.

Ideally, the load should be spread evenly across several differentservers. A simple way to do this is to set up p servers and assign eacha unique number in the range 0 to 2^(P-1) Next, for every credit cardnumber that must be verified, check a prespecified set of p bits of thecredit card number and assign the verification to the server with thecorresponding number. For example, if the p specified bits of the creditcard number give “14,” assign the verification to the server numbered“14.”

For the primary embodiment, there are 2⁵³ possible credit card numbers.A central authority might be established to assign ranges of accountnumbers to individual credit card companies. Once a company receives anr-bit range of account numbers it may further split the range of numbersup as desired. Ultimately the issuer should decide upon the size of thenonce (n bits), the account number (a bits), and the size of the IV (mbits) so that n+a+m=r. Note that the account number should include thosebits assigned by the central authority. Also, different card holders canhave different values of n, a, and m even if they receive their cardsfrom the same credit card company.

After a cardholder's card expires, his account number can be reused. Thenext credit card issued with that account number would use a differentnonce and private key. This will ensure that any credit card numbersgenerated with the old credit card will not match any new credit cardnumbers with better than random chance.

In an alternative to the present embodiment, timestamps could beincluded with the nonce during encryption. Then, credit cards could beused in conjunction with a clock. When creating the credit card thecredit card issuer should start the clock at 0 and note the offset fromits own clock, storing the difference with the card holder's accountinformation (for example in the database 411). Then when a credit cardissuer desires to validate a timestamp created by the credit card, itmay simply add the timestamp to the offset stored with the card holder'saccount and then compare the result against its own clock. If the timefalls within a specified time window then the timestamp should beconsidered valid.

In order for the credit card issuer to verify a single-use credit cardnumber, it must know to which account the credit card number belongs.Instead of encoding the account number as part of the credit cardnumber, the name that appears on the card could take the place of theaccount number. In that case every credit card must have a differentname printed on the card. The trade-off in this instance is that manymore bits become available in the credit card number since they are notused to encode the account number. They can then be used to encode atimestamp, purchase information, or even merchant information.

SECOND EMBODIMENT Lists of Single-Use Credit Card Numbers

In this embodiment, the device memory 104 includes a database with alist of single-use credit card numbers and a flag for each numberindicating whether the number has already been used. The single-usecredit card numbers are assigned to the cardholder by the credit cardissuer.

One method to assign single-use credit card numbers is as follows. Thereare 2⁵³ possible credit card numbers. Some sort of central authoritycould assign ranges of account numbers to individual credit cardcompanies. Once a company receives an r-bit range of account numbersthey can further split the range of numbers up however they please.Ultimately, the credit card company would decide upon the size of thenonce (N bits), the account number (A bits), and the size of the IV (mbits) so that n+a+m=r. The account number would include those bitsassigned by the central authority. Also, different card holders can havedifferent values of n, a, and m even if they received their cards fromthe same credit card company. It is simply up to the company to keeptrack of the appropriate information.

After a card holder's card expires their account number can be reused.The next credit card issued with that account number should use adifferent nonce and private key. This will ensure that any credit cardnumbers generated with the old credit card will not match any new creditcard numbers with better than random chance.

The steps for obtaining a single-use credit card number according tothis embodiment are shown in FIG. 10. In step 1001, the cardholderenters his unique identifier (for example, a PIN or biometric data) intothe device. The device determines whether the identifier is valid forthe device (step 1002); if not, access to the device is denied (step1004). If the identifier is valid, the device searches the single-usecredit card number database in the device memory 104 for a single-usecredit card number (step 1003). If a single-use credit card number isavailable (step 1005), it is displayed on the device display screen 102(step 1007); if not, a message is displayed instructing the cardholderto obtain a new device (with a new list of single-use credit cardnumbers) from the credit card issuer (step 1006). The database in thedevice memory 104 is then updated to change the status of the numberfrom “not used” to “used” (step 1008).

A schematic diagram of the credit card issuer's central processoraccording to this embodiment is shown in FIG. 12. The processor 1200includes a central processing unit (CPU) 1201. The CPU is connected to aclock 1202, a random-access memory (RAM) 1203, a read-only memory (ROM)1204, and a communication port 1206 for communication with themerchant's central processor, similar to the first embodiment. Inaddition, the CPU 1201 is connected to a data storage device 1210, whichincludes a credit card account holder database 1211, a credit cardnumber database 1212, and a credit card transaction database 1213. Thecredit card account holder database 1211 has the same structure asdatabase 411.

The fields of the credit card number database 1212 are shown in FIG. 13.Each cardholder account number 501 is associated with the cardholdername 502 and a list of credit card numbers 1301; each credit card numberhas associated therewith its status 1302 (used or not used).

The fields of the credit card transaction database 1213 are shown inFIG. 14. Each record of this database corresponds to one transactionusing the card, and includes the account number 501, the expiration date507 of the card, the transaction amount 702, and the merchantidentification number 703.

The steps for generating an authorization code for a credit transactionin this embodiment are shown in FIGS. 11A and 11B. In step 1101, thecardholder provides the merchant with a single-use credit card numberdisplayed on the device (see step 1007 of FIG. 10). The merchant thentransmits the single-use credit card number and the transaction amountto the credit card issuer's central processor 1200 (step 1102). Thecentral processor searches the credit card number database 1212 toidentify the account holder of the transmitted single-use credit cardnumber (step 1103), and determines whether the transmitted credit cardnumber matches a credit card number listed in the credit card numberdatabase (step 1104). If there is no match, the credit card number isconsidered invalid, and the transaction is aborted (step 1105). If thereis a match, the credit card number is considered valid, and the centralprocessor checks the status 1302 of the credit card number to determinewhether the credit card number has already been used (step 1106). If so,the number is no longer valid, and the transaction is aborted (step1107).

If the cardholder's account meets the credit card issuer's approvalcriteria (step 1121), then the issuer's central processor generates anauthorization code and transmits the code to the merchant (step 1123).If not, the transaction is aborted (step 1122). Finally, in step 1124,the issuer's central processor changes the status 1302 of the creditcard number from “not used” to “used.”

While the present invention has been described above in terms ofspecific embodiments, it is to be understood that the invention is notlimited to the disclosed embodiments. On the contrary, the presentinvention is intended to cover various modifications and equivalentstructures included within the spirit and scope of the appended claims.

1. In a financial transaction system for use with at least one limiteduse credit card number, which is limited in use by a limited use creditcard number issuer and by a user of the limited use credit card number,and which is associated with an account of the user, a method ofcontrolling the authorization for use of the limited use credit cardnumber comprising the steps of: issuing a limited use credit card numberfor use by a user in a limited use credit card number transaction, thelimited use credit card number constituting a different number than theaccount of the user and functioning as an authorized substitute for theaccount of the user in a credit card transaction; receiving informationcommunicated by the user to the limited use credit card number issuer toestablish limitations on the use of the limited use credit card numberbefore the limited use credit card number can be used in a transactionby said user; authorizing transactions which meet said establishedlimitations and denying other transactions by comparing an attempted useof the limited use credit card number to the limitations on useestablished by the user and with the associated account as limited bythe card issuer; and debiting said associated account of the user by anamount of an authorized transaction of the user using the limited usecredit card number.
 2. The method of claim 1, wherein said uselimitations include a combination of a pre-set transaction amount limitand a merchant.
 3. The method of claim 1, wherein the account of theuser is not revealed to a merchant when the limited use credit cardnumber is used in a transaction by the user.
 4. The method of claim 1,wherein the limited use credit card number is formatted as a credit cardnumber for processing by a merchant to whom the limited use credit cardnumber is presented in a transaction by the user.
 5. The method of claim4, wherein the user presents the limited use credit card number directlyto the merchant in person or via a communication network through which acommunication device of the user and a communication device of themerchant are communicatively linked.
 6. The method of claim 4, whereinthe user presents the limited use credit card number directly to themerchant in person.
 7. The method of claim 1, wherein the limited usecredit card number is a single-use credit card number.
 8. The method ofclaim 1, wherein the user is also a cardholder for the associatedaccount.
 9. The method of claim 1, wherein the use limitations include aPIN of the user.
 10. The method of claim 1, wherein the use limitationsinclude biometric data of the user.
 11. The method of claim 1, whereinthe use limitations include the amount of the authorized transaction.12. The method of claim 1, wherein the use limitations include amerchant code number.
 13. The method of claim 1, wherein the usertransmits the limited use credit card number to the merchant remotely.14. In a financial transaction system for use with at least one singleuse credit card number, which is limited in use by a single use creditcard number issuer and by a user of the single use credit card number,and which is associated with an account of the user, a method ofcontrolling the authorization for use of the single use credit cardnumber comprising the steps of: issuing a single use credit card numberfor use by a user in a single use credit card number transaction, thesingle use credit card number constituting a different number than theaccount of the user and functioning as an authorized substitute for theaccount of the user in a credit card transaction; receiving informationcommunicated by the user to the single use credit card number issuer toestablish limitations on the use of the single use credit card numberbefore the single use credit card number can be used in a transaction bysaid user; authorizing transactions which meet said establishedlimitations and denying other transactions by comparing an attempted useof the single use credit card number to the limitations on useestablished by the user and with the associated account as limited bythe card issuer; and debiting said associated account of the user by anamount of an authorized transaction of the user using the single usecredit card number.
 15. The method of claim 14, wherein said uselimitations include a combination of a pre-set transaction amount limitand a merchant.
 16. The method of claim 14, wherein the account of theuser is not revealed to a merchant when the single use credit cardnumber is used in a transaction by the user.
 17. The method of claim 14,wherein the single use credit card number is formatted as a credit cardnumber for processing by a merchant to whom the single use credit cardnumber is presented in a transaction by the user.
 18. The method ofclaim 17, wherein the user presents the single use credit card numberdirectly to the merchant in person or via a communication networkthrough which a communication device of the user and a communicationdevice of the merchant are communicatively linked.
 19. The method ofclaim 17, wherein the user presents the single use credit card numberdirectly to the merchant in person.
 20. The method of claim 14, whereinthe user is also a cardholder for the associated account.
 21. The methodof claim 14, wherein the use limitations include a PIN of the user. 22.The method of claim 14, wherein the use limitations include biometricdata of the user.
 23. The method of claim 14, wherein the uselimitations include the amount of the authorized transaction.
 24. Themethod of claim 14, wherein the use limitations include a merchant codenumber.
 25. The method of claim 14, wherein the user transmits thesingle use credit card number to the merchant remotely.